Computerized systems commonly store data that is critical in nature, or that if lost could only be recreated with great difficulty, if at all. Therefore, it is common to back up files so that they can be restored if needed. For example, a storage device storing the files may fail, such that the backup copy of the data files stored on a different storage device can instead be used. As another example, a user may accidentally delete a needed data file, such that the backup copy of the data file allows the user to restore the data file. As a final example, a needed file may become corrupted by incorrect system operation, such that the backup copy of the file can be used.
Data is commonly stored within a file system, which specifies the approach for storing and retrieving files on a hard disk drive or other storage device. For instance, a file system defines the directory structure for keeping track of the files and the path syntax required to access them. The file system may also define the way files are named as well as the maximum size of a file or volume. A file system particularly stores file system objects, where each file system object can refer to a data file, a directory structure, or another type of data that is stored on the hard disk drive or other storage device in question.
Backing up a file system thus can involve backing up all the file system objects stored on a given hard disk drive or other storage device. By backing up all the file system objects of a file system, even if the hard disk drive or other storage device fails in an unrecoverable manner, the data stored thereon is not lost. Rather, the file system objects of the file system can be recreated based on the backup copy of the file system objects.
A file system may be backed up to a tape backup device. For example, some versions of the Microsoft Windows® operating system employ the NT file system (NTFS). Backing up a hard disk drive that stores file system objects in accordance with the NTFS thus typically involves using a backup application running on the Microsoft Windows® operating system, and therefore in relation to the NTFS. The backup application typically retrieves all the file system objects stored on the hard disk drive, and stores them on a tape inserted into the tape backup device. Because the hard disk drive stores file system objects in accordance with the NTFS that is used by the Microsoft Windows® operating system itself, backup is easily accomplished, because the operating system has knowledge of all the different types of file system objects that may be stored on the hard disk drive.
More recently, heterogeneous file systems have become more common, in which file system objects are stored for and by a variety of different operating systems. For example, storage-area network (SAN) file systems may be employed to store file system objects from computing devices running in relation to the Microsoft Windows® operating system, the LINUX® operating system, the UNIX® operating system, as well as other types of operating system. That is, computing devices running the Microsoft Windows®, the LINUX®, and the UNIX® operating systems, for instance, may all store file system objects on the same hard disk drives of the same SAN file system.
A SAN file system may run one type of file system, such as the SANFS available from International Business Machines, Inc., of Armonk N.Y., but the SANFS is able to store file system objects consistent with the file systems that individual computing devices typically use. For instance, a computing device running the Microsoft Windows® operating system may store file system objects to the SAN file system as if the SAN file system were the NTFS. Similarly, computing devices running the LINUX® and the UNIX® operating systems may store file system objects to the SAN file system as if the SAN file system were the LINUX® and the UNIX® file systems, respectively. That is, a computing device running the UNIX® operating system, for example, is able to store file system objects to the SAN file system no different than if the computing device were storing file system objects to the UNIX® file system.
Therefore, a backup application running on a computing device in relation to one type of operating system, and that is to back up all file system objects stored on the SAN file system, may encounter file system objects of which its operating system and typical file system do not have knowledge. For example, there may be types of file system objects that are present on the SAN file system that have been stored by computing devices running the UNIX® or the LINUX® operating system, as if the SAN file system were the UNIX® or the LINUX® file system. These file system objects are not known to the NTFS that is used with the Microsoft Windows® operating system. That is, computing devices running the UNIX® and the LINUX® operating systems may store file system objects on the SAN file system that are not known to the backup application, because the backup application may be running on the Microsoft Windows® operating system, and thus is only knowledgeable of file system objects that are particularly known to the NTFS. Because the backup application running on the Microsoft Windows® operating systems accesses the SAN file system no different than if it were the NTFS, it is knowledgeable only of file system objects that are particularly known to the NTFS.
As a result, some types of file system objects may not be able to be backed up properly by a backup application running on the Microsoft Windows® operating system and that expects all file system objects to be known to the NTFS, since it accesses the SAN file system no different than if it were the NTFS. For instance, within the UNIX® and the LINUX® file systems, there are types of file system objects that have no direct counterparts within the NTFS. For example, such file system object types include symbolic links, named pipes (also known as first-in-first-out pipes), and special device files. A symbolic link is a type of file system object that allows nearly transparent reference to a target directory entry, such as a target file or a target directory. Thus, referencing the symbolic link in actuality references another file system object, such as a target file or a target directory.
A named pipe is a type of file system object that is used to transfer data between two unrelated processes. One or more processes write data to the pipe, where the pipe is referenced as a file system object, even though the data is usually stored in volatile memory apart from the file system in question. One or more other processes thus read the data from the pipe. The data is processed in a first-in, first-out (FIFO) manner, and the data is consumed, or erased, as it is read. Finally, a special device file is a file that references a device, such as a printing device, for example, so that input/output (I/O) to the device is accomplished in the same way that I/O is normally accomplished in relation to a file. A special device file is a special file in that it does not contain data, like a regular file does, or information about other files, like a directory does.
Backup applications running on operating systems that access a SAN file system as if it were the NTFS, or another file system that itself does not employ symbolic links, named pipes, and special device files, thus cannot inherently back up these types of file system objects. A backup application running on the Microsoft Windows® operating system and thus in relation to a SAN file system as if it were the NTFS, and that is attempting to back up these types of file system objects from a SAN file system, will read the data of the file system objects, but will not be able to instruct the SAN file system to recreate the file system objects properly if or when later such restoration is required. For example, the backup application is able to retrieve a file system object from a SAN system corresponding to a special device file, and is able to store the file system object, such as on a tape inserted into a tape drive. However, if or when the backup application needs to restore the file system object back to the SAN file system, it is not able to instruct the SAN file system that the file system object is a special device file, and thus should be recreated as such. Therefore, the special device file is not likely to be recreated correctly.
There is thus a need that overcomes these deficiencies within the prior art. That is, there is a need within the prior art for file system backup, in which all the file system objects that may be stored on a file system are able to be backed up, and subsequently restored, even when the backup application is running on an operating system that is typically used with a type of file system that does not have knowledge of the types of some of the file system objects. For this and other reasons, therefore, there is a need for the present invention.